It seems unfortunate that this doesn't show off the use of a CSR (mainly in order to show off how this can be done with the CA's key sitting in another process).

(I'll just link my old example here again: https://github.com/djc/sign-cert-remote/blob/main/src/main.rs.)

I didn't see this example before. What I have done for now is add a comment to the top of the example that links to your more complete example. The only advantage I see of the one in this PR is simplicity. So it seems reasonable to me to have this very simple example here but have the obvious link to the more complete example. If your preference is to copy your example in to this repo as an example, I can replace the example already in the PR with that one. I can also see that this PR might be superfluous given that the more complete example already exists.

The rest of the comments on the PR have been addressed.

@cpu I have added the parameters to comply with standards. @djc I basically copied the same structure from your other example in order to bring in the CSR logic. Unfortunately, serialize_request_pem panics with the extra parameters added in the latest commit. So I have removed serialization of the indirect certificate. I can think a bit more about this later, but for now I've pushed the changes that resolve the rest of the comments.

Thanks!

Unfortunately, serialize_request_pem panics with the extra parameters added in the latest commit.

I think that will be resolved w/ #164 - right now not every extension that can be created from CertificateParams can be written to a CSR. There's code in main rejecting KU, EKU, and AKI when serializing a CSR from params.

So I have removed serialization of the indirect certificate.

That makes sense to me. We can extend the example when the CSR limitation is addressed by #164 (or another PR).

Here's some initial feedback, but I think the build failures in CI are also true positives to work through.

I addressed your comments and builds seems to be passing now.

Sorry for getting so late to the discussion. First a general point: I must say that I disagree with the opinion of @cpu to generally move rcgen to conform by CA/Browser forum rules. Yes, they are made by the professionals in the CA industry, those who issue certificates as a paid service. And it is valuable to have these rules apply to most TLS certificates you use to connect to random web services.

But it feels to me that most users of rcgen are not the "professionals", so they don't really need to conform by these rules. And in my opinion, the professional's rules are quite harmful for users.

• The created certificates are now way bigger than they used to be, causing bloat. This means you cannot paste them as easily in the text form and are more likely to move them around as files.
• Any additional complexity makes it hard to customize the certificates to the use case needed by the user of rcgen.
• The worst part is probably not allowing certificates which last thousands of years. In many settings you don't really want to do key rotation or certificate renewal, and have no plans set up for that. I've heard many people reject all of TLS as a technology because of this strong enforcement of certificate renewal. In rcgen's use cases, often you have not really planned key rotation or certificate renewal. You deploy some device in the field, a certificate becomes invalid, and then boom, the device doesn't work any more.

To me, it feels that the CA/Browser forum rules are mostly relevant if you are either a member of that forum, or if you otherwise want to create certificates that are trusted by browsers by default. I don't think most users of rcgen are/want to do either, and I built rcgen to serve their needs (which was also my need).

The big browsers don't enforce most of these rules, at least for locally trusted certificates. For trusted-by-default certificates, it's a different thing, which is again fine and a good idea. But locally trusted certificates don't need this info, you know already that they have local trust.

I am in favour of adding a "CA/Browser Forum compliance" mode which enables the appropriate extensions for various scenarios, it could e.g. be different constructors of CertificateParams. But I don't think rcgen should output certificates that expire less than 1 year after issuance by default. That's way more btw than what chrome requires for (newly issued) globally trusted certificates, so it would really just be something that ticks a random checkbox somewhere while disrupting users in the field.

Now to the specific point. I think it's fine to have one or two examples that create CA/Browser Forum compliant certificates, just to show users who need it (they should be in a minority) how it's done. But I don't think we should use it in all examples, or even a majority.

First a general point: I must say that I disagree with the opinion of @cpu to generally move rcgen to conform by CA/Browser forum rules.

@est31 Fair, but I don't want to side-track this PR arguing my perspective. It sounds like it would be an uphill battle in either case.

But it feels to me that most users of rcgen are not the "professionals"

For what its worth I think this is a strong argument for why opinionated defaults are in order.

Now to the specific point. I think it's fine to have one or two examples that create CA/Browser Forum compliant certificates, just to show users who need it (they should be in a minority) how it's done. But I don't think we should use it in all examples, or even a majority.

It sounds like the changes I suggested are fine for the example at hand? If not I think it would be helpful to the OP if you leave some specific suggestions about what needs to change to land this example.

I do think I agree that getting this example to go through the CA/B hoops might not be worth it/increases scope too much for this PR, especially if we're planning to offer an API in the library that handles these details for you (so that we can then remove the code in this example again).

In general, it would be great if we can facilitate all three use cases:

• Test certificates (simple, long-lived)
• Custom deployment (diverse concerns, but making long-lived certificates easy)
• CA/B-compliant certificates

Which seems feasible enough to me? For example, we could offer CA/B forum defaults, but under a specific API (like CertificateParams::web_server() or some such).

getting this example to go through the CA/B hoops might not be worth it/increases scope too much for this PR

The changes I requested have already been made and don't seem to increase the scope by much to me. It's a handful of small changes.

I think we should defer discussion of future API changes to a separate issue and focus on providing actionable feedback to the contributor. If there are parts of the work that are out of scope, let's suggest changes to bring it in-scope.

Sorry for the off-topic discussion. I am approving this PR.

getting this example to go through the CA/B hoops might not be worth it/increases scope too much for this PR

The changes I requested have already been made and don't seem to increase the scope by much to me. It's a handful of small changes.

I think we should defer discussion of future API changes to a separate issue and focus on providing actionable feedback to the contributor. If there are parts of the work that are out of scope, let's suggest changes to bring it in-scope.

Fair enough, sorry!

cpu force-pushed the sign-leaf-with-ca-example branch from a75cbc3 to aa2caf9

Squashed the review commits so the merge queue rebase merge will be tidy.